昨天寫到最後，我留下一個問題：

從一個模糊 Idea 出發，它應該怎麼一步一步把需求問清楚？

這就是今天要開始處理的部分。

昨天整理出來的結論是：Prompt 解決的是「怎麼跟 AI 說」，Requirement 解決的是「到底要做什麼」。如果一個產品本身還有很多事情沒有決定，就算把 Prompt 寫得再完整，AI 還是只能自己把那些空白補起來。

所以問題來了。

如果 ClarifyBuild 的目的不是單純幫我「把 Prompt 寫漂亮一點」，那它到底應該做什麼？

我目前的答案是：

在進入 Build 之前，先找出 Idea 裡還沒有被決定的事情，再一步一步把它問清楚。

也就是：

Idea
  ↓
Clarify
  ↓
Requirement
  ↓
Specification
  ↓
Build

前四天一直在談前面的問題。

今天終於要開始碰 Clarify 這一層了。

先拿一個模糊 Idea 來試

假設今天我只輸入：

我想做一個活動報名網站。

乍看之下，這好像已經是一個需求。

甚至直接丟給 AI，它大概也可以馬上開始幫我做：

• 首頁
• 活動資訊
• 報名表單
• 送出按鈕
• 成功頁面

幾分鐘後，也許真的會得到一個「看起來可以用」的網站。

但經過前幾天的拆解後，我現在看到這句話，第一個反應反而是：

還不能做。

因為裡面其實還有很多事情不知道。

例如：

• 是什麼活動？
• 誰可以報名？
• 一個人只能報名一次嗎？
• 報名需要登入嗎？
• 需要限制名額嗎？
• 額滿之後怎麼辦？
• 使用者可以修改報名資料嗎？
• 要不要寄確認信？
• 管理者需要看到報名名單嗎？
• 報名成功到底代表什麼？

這些問題比 UI 細節重要得多，它們決定的是：

這個產品到底要怎麼運作。

而這也是我希望 ClarifyBuild 幫忙處理的地方。

ClarifyBuild 不應該只是「多問幾個問題」

一開始我其實很容易把 ClarifyBuild 想成一份需求問卷。

例如輸入 Idea 之後，系統固定問：

1. 你的目標使用者是誰？
2. 你的產品目標是什麼？
3. 需要哪些功能？
4. 有哪些限制？
5. 希望使用什麼技術？

這樣當然比直接寫 Prompt 好。

但我後來發現，固定問一堆問題，好像還是不太對。

因為不同 Idea 缺少的資訊並不一樣。

例如：

做一個個人作品集網站。

和：

做一個可以讓學生預約老師時間的系統。

需要釐清的事情明顯不同。

前者可能比較需要確認：

• 要展示哪些內容？
• 有沒有作品分類？
• 是否需要聯絡表單？

後者卻會碰到：

• 誰可以預約？
• 時段由誰建立？
• 可以取消嗎？
• 同一時段能不能多人預約？
• 預約衝突怎麼處理？

如果 ClarifyBuild 不管使用者輸入什麼，都照著同一份表單問到底，那其實只是把「寫 Prompt」變成「填表單」。

這不是我真正想做的。

我真正想處理的是「未決定事項」

所以今天我幫 ClarifyBuild 換了一個思考方式。

它不是先問：

「我要準備哪些固定問題？」

而是先問：

「如果現在開始開發，AI 還需要自己決定哪些事情？」

只要答案是「還有」，就要再判斷這個空白是否重要到值得 Clarify。

換句話說，我現在想把 Clarification 理解成：

找出需求中的空白
        ↓
判斷哪些空白會影響產品行為
        ↓
向使用者提出問題
        ↓
取得決定
        ↓
更新目前的 Requirement
        ↓
再次檢查還有沒有重要空白

這跟「一次問完十個問題」不太一樣。

它比較像一個逐步收斂的過程。

第一版 Clarification Flow

目前我先把 ClarifyBuild 的需求釐清流程拆成五個步驟。

Step 1：先理解 Idea

第一步先不要急著產生 Spec。

系統要先理解使用者大概想做什麼。

例如：

我想做一個活動報名網站。

這時候至少可以先辨認出：

Product：活動報名網站
Core Action：報名活動

但這只能算是起點。

Step 2：找出目前還不知道的事情

接下來才是 ClarifyBuild 真正重要的部分。

系統需要判斷：

如果現在直接開始 Build，有哪些地方 AI 必須自己猜？

以活動報名網站為例，可能會得到：

Unknown

- Target User
- Registration Rule
- Capacity Rule
- Confirmation Method
- Edit / Cancel Rule
- Admin Requirement

我覺得這個 Unknown 很重要。ClarifyBuild 沒有必要假裝需求已經完整，老實承認一句：

這裡還不知道。

這才是它該做的事。

Step 3：一次解決一個重要問題

接著 ClarifyBuild 才開始提問。

但我不希望畫面一次出現二十題。

比較理想的方式是，一次處理一個真正會影響產品的問題。

例如：

誰可以報名這個活動？

選項可能是：

• 所有人都可以
• 只有登入會員
• 只有收到邀請的人
• 其他

使用者回答：

所有人都可以，不需要登入。

這時候原本的：

Target User：Unknown
Authentication：Unknown

就可以更新成：

Target User：General Public
Authentication：Not Required

需求開始慢慢從模糊變成具體。

Step 4：把答案轉成 Requirement

這也是我覺得很容易忽略的一步。

如果 ClarifyBuild 只是保存：

Q：需要登入嗎？
A：不用。

那最後只會累積一堆問答紀錄，沒辦法直接交給 AI 繼續開發。

我真正要的，是可以繼續往 Specification 整理、最後交給 AI 開發的 Requirement。

所以：

Q：使用者報名前需要登入嗎？

A：不用。

應該轉換成：

Requirement:
Users can register for an event without creating an account or logging in.

再例如：

Q：活動有人數限制嗎？

A：最多 50 人。

應該逐漸變成：

Requirement:
The system must limit successful registrations to 50 participants.

這樣 Clarification 才真的有往 Specification 靠近。

Step 5：持續檢查，直到需求足夠清楚

回答完一題之後，也不代表需求就完成了。

因為一個答案可能又帶出新的問題。

例如使用者說：

活動最多 50 人。

那下一個問題可能就出現了：

第 51 個人送出表單時要發生什麼事？

可能是：

• 顯示額滿
• 進入候補
• 仍可留下資料
• 關閉報名入口

如果畫成清單，Clarification 看起來可能會像這樣：

Question 1
Question 2
Question 3
Question 4
Finish

但實際跑起來，比較像一個會不斷繞回來的迴圈：

Idea
 ↓
Find Unknown
 ↓
Ask
 ↓
Decide
 ↓
Update Requirement
 ↓
Find New Unknown
 ↓
Ask Again
 ↓
...
 ↓
Ready for Next Step

我目前覺得這才比較接近 ClarifyBuild 真正應該做的事。

什麼事情值得問？什麼不用問？

做到這裡又出現另一個問題。

如果所有細節都要問，ClarifyBuild 很快就會變成超級煩人的系統。

例如：

按鈕要圓角幾 px？

Header 高度要多少？

卡片陰影要多深？

這些事情當然也是決定。

但它們不一定都值得在開發前打斷使用者。

所以我目前先訂一個很粗略的原則：

如果不同答案會明顯改變產品功能、流程、資料或成功條件，就優先 Clarify。

例如：

這也讓我開始看到 ClarifyBuild 的一個重要邊界：

把那些不應該默默交給 AI 猜、而且會影響產品方向的決策找出來。

不是每個決定都要丟回給使用者，但這種決定不行。

從「AI 幫我決定」變成「AI 幫我發現還沒決定」

這幾天一路做到這裡，我覺得自己對 AI 在 Vibe Coding 裡面的角色也有一點改變。

以前比較像：

我提出 Idea
↓
AI 幫我補完整
↓
AI 開始 Coding

但 ClarifyBuild 想做的事情比較像：

我提出 Idea
↓
AI 幫我找到還沒決定的地方
↓
我做出產品決定
↓
AI 把決定整理成 Requirement
↓
再進入 Build

兩種流程看起來只多了一個 Clarify。

但產品最後會長成什麼樣子，可能就是在這裡開始分開。

我更擔心的，甚至不只是 AI 把程式寫錯，而是程式明明寫對了，AI 做出來的卻是它自己想像中的產品，跟我真正想做的不一樣。

ClarifyBuild 第一版流程出現了

所以目前 ClarifyBuild 從 Idea 到 Build 的流程，我先收斂成：

Idea
  ↓
Identify Unknowns
  ↓
Ask Clarifying Question
  ↓
User Decision
  ↓
Update Requirement
  ↓
Check Remaining Unknowns
  ↓
Specification
  ↓
Build

如果再把它縮短一點，就是：

Idea → Clarify → Requirement → Specification → Build

這也是前幾天一直出現的那條流程。

只是到了今天，它終於不再只是一條概念上的箭頭。

我開始知道 Clarify 裡面到底要發生什麼事了。

Day 5 小結

今天還沒有開始寫 ClarifyBuild 的程式。

但我覺得這一步反而不能省。

因為如果連 ClarifyBuild 自己的需求都還沒想清楚，就直接開始 Vibe Coding，好像又會回到這整個系列一開始想解決的問題。

目前我先確定三件事：

1. ClarifyBuild 不是 Prompt Generator。
2. Clarification 的核心是找出「尚未決定、但會影響產品」的事項。
3. 使用者的回答要逐步整理成 Requirement，不能只停在問答紀錄裡。

而接下來還有一個更現實的問題。

如果 ClarifyBuild 可以一直問、一直補、一直延伸功能，那我要做到什麼程度才算完成？

哪些東西是第一版一定要有的？

哪些功能雖然很好，但這次應該先不要做？

所以明天我要開始替 ClarifyBuild 畫出第一版的範圍：MVP 與 Scope。

有時候做產品最難的部分，可能不是再想到什麼，而是決定這次先不要做什麼。

Day 5 完成。

明天見。